Typically, troubleshooters follow an iterative troubleshooting process or pattern. This may be a sequence of steps in a troubleshooting session, where a troubleshooter may execute troubleshooting queries in a system, examine the results, and then drill down further by executing additional queries till the root cause of the problem is identified. In practice, troubleshooting within a relatively large computing environment is not a simple sequence of steps. For example, the user might navigate through many different nodes in a manner that can be backwards, forwards, sideways, or randomly, as opposed to a single direction. As a result, it may become difficult to keep track of the various searches performed, the order in which they were performed, and to track each search result in the context of the query.
In general, troubleshooting may require deep domain expertise in each of the solution components of the system. Further, troubleshooting is highly collaborative, and largely a manual process. This often increases the turnaround time for resolving issues e.g. as measured by support ticket closure duration.
For example, experienced troubleshooters, over time, develop a mental library of troubleshooting patterns mapped to frequently observed issues or data, and they use this tribal knowledge to achieve faster issue resolution. However, this is largely dependent on the experience of the troubleshooter and it takes time for a novice troubleshooter to come up to speed. Further, some conventional methods may lack context sensitive troubleshooting guidance. For example, even if these patterns are documented in certain documents or articles (e.g., KB articles), they are often difficult to use and maintain, and are not available in the context of a specific troubleshooting step. In addition, as systems change, the issues observed also change and hence existing troubleshooting patterns may lose their relevance. Troubleshooters will again need time to learn the new patterns and exploit them.